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This  article  will  discuss  the  merging  of  Unified  Modeling  Language  (UML)  with  “what you  see  is  what  you  get”  (WYSIWYG) 
graphical  user  interface  ( GUI)  tools.  The  topics  presented — and  discussion  of  an  example  with  benefits  and  hazards — will 
show  that  the  merged  solution  can  increase  productivity  and  provide  an  improved  rapid  prototyping  platform. 


This  article  is  based  on  the  current 
work  done  on  a  project  at  Hill  Air 
Force  Base,  which  is  based  on  the  Team 
Software  ProcessSM  (TSPSM)  practices  in 
the  CMMI®  Level  5  organization.  One  of 
the  requirements  of  our  customer  is  that 
the  project  should  use  a  model-driven 
design  UML  toolset,  namely  Rational 
Rose  RealTime.  This  project  is  tasked  with 
the  design  and  development  of  a  real-time 
control  system  based  on  C++  auto-gener¬ 
ated  code.  In  addition,  the  project  selected 
to  use  the  Tilcon  Interface  Development 
Suite  (IDS)  in  order  to  rapidly  and  effi¬ 
ciently  create  graphical  interfaces  for  the 
real-time  control  system  that  generates 
stunning  displays  to  the  operators  of  the 
system  at  a  fraction  of  the  time  or  exper¬ 
tise  otherwise  needed. 

Overview  of  UML 

The  focus  of  UML  is  to  model  systems 
using  object-oriented  concepts  and 
methodology.  UML  consists  of  a  set  of 
model  elements  that  standardize  the 
design  description.  These  elements 
include  a  number  of  fundamental  basic 
model  elements  and  modeling  concepts,  in 
addition  to  views  that  allow  designers  to 
examine  a  design  from  different  perspec¬ 
tives  and  diagrams  to  illustrate  the  rela¬ 
tionships  among  model  elements. 

Several  views — such  as  Use  Case  View, 
Logical  View,  Component  View,  Concur¬ 
rency  View,  and  Deployment  View — cre¬ 
ate  a  complete  description  of  the  system 
design.  Within  each  view,  an  organized  set 
of  diagrams  and  other  model  elements  are 
visible.  Diagrams  include  use  case  dia¬ 
grams,  class  diagrams,  object  diagrams, 
sequence  diagrams,  collaboration  dia¬ 
grams,  state-chart  diagrams,  activity  dia¬ 
grams,  component  diagrams,  and  deploy¬ 
ment  diagrams.  Some  key  primitive  model 
elements  are  states,  transitions,  signals, 
classes,  class  roles,  attributes,  and  opera¬ 
tions  [1]. 
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The  object-oriented  principles  (OOP) 
used  for  the  UML  design  and  develop¬ 
ment  are  based  on  the  idea  of  creating 
self-contained  modules  that  describe 
desired  functionality  and  interact  with  oth¬ 
ers  through  interfaces  in  order  to  create  a 
complete  system.  To  achieve  this  goal, 
some  of  the  techniques  available  with 
OOP  include  encapsulation  and  abstrac¬ 
tion  [2,  3]. 

“The  UML  language  is 
complete  enough  to 
allow  the  creation  of 
auto-generated  code  that 

implements  the  design. 

The  code  can  be 
generated  from  the 
system  description  of  the 
model  through  the  use  of 
diagrams  and  other 
model  elements.*9 

Encapsulation  describes  the  grouping 
of  related  functionality,  which  separates 
implementation  from  interface.  The 
implementation  details  are  hidden  from 
outside  users,  who  can  only  interact  with 
objects  of  the  class  through  the  interface. 
In  this  way,  the  implementation  can  be 
more  easily  changed. 

Abstraction  provides  characteristics  of 
the  object  or  a  class  that  are  unique  and 
creates  specific  defined  boundaries  with 
respect  to  the  currently  desired  solution. 
Abstraction  allows  a  way  of  managing  sys¬ 
tem  complexity  by  hiding  irrelevant 
details.  For  example,  it  allows  for  develop¬ 
ment  to  continue  if  a  class  is  just  a  place¬ 
holder  for  future  implementation. 


UML  Elements  for  Real-Time 
Systems  Design 

Designing  real-time  systems  is  a  challenge. 
To  address  this  challenge,  an  active  class 
model  element  was  introduced  in  UML. 
The  purpose  of  this  element  was  to  help 
simplify  both  the  design  and  the  imple¬ 
mentation. 

The  active  class  model  element  con¬ 
sists  of  a  communication  structure 
description  and  a  behavioral  description. 
The  communication  structure  is  described 
using  a  collaboration  diagram  that  shows 
the  ports  through  which  it  sends  and 
receives  messages  to  and  from  other  active 
classes.  The  behavior  is  described  using  a 
state  transition  diagram  that  shows  how 
the  active  class  acts  and  reacts  to  its  envi¬ 
ronment1.  In  other  words,  the  active  class 
is  a  stand-alone  capsule  of  software  that 
talks  to  its  environment  through  ports 
(specified  in  the  structure  diagram),  and 
performs  actions  as  it  transitions  through  a 
sequence  of  states  (specified  by  the  state 
diagram). 

The  characteristics  of  a  run-time  sys¬ 
tem  (RTS)  object  and  the  UML  active 
class  were  determined  to  simplify  the 
process  of  real-time  software  design  and 
implementation.  In  addition,  by  encapsu¬ 
lating  calls  to  the  operating  system  of  the 
target  platform  within  the  RTS,  the  auto¬ 
generated  implementation  of  the  UML 
design  can  be  made  largely  platform-inde¬ 
pendent. 

The  UML  language  is  complete 
enough  to  allow  the  creation  of  auto- 
generated  code  that  implements  the 
design.  The  code  can  be  generated  from 
the  system  description  of  the  model 
through  the  use  of  diagrams  and  other 
model  elements  [4]. 

Overview  of  WYSIWYG 
GUI  Tools 

The  WYSIWYG  concept  is  a  well-known 
technique  that  states  that  the  end-product 
will  look,  act,  and  behave  the  same  way  as 
it  does  being  designed  on-screen  from  the 
developer  to  the  end-customer  look  and 
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Figure  1 :  Tilcon  IDS 


State 

Description 

Attributes 

Initial 

System  not  running 

Timer  event  set  to  30  seconds 

Green 

On  timer  time  out  event  go  to 
(goYellow)  Yellow 

Timer  event  set  to  45  seconds 

Yellow 

On  timer  time  out  event  go  to 
(goRed)  Red 

Timer  event  set  to  10  seconds 

Red 

On  timer  time  out  event  go  to 
(goGreen)  Green 

Timer  event  set  to  30  seconds 

Table  1 :  State  Specification  Template  for  the  Sequence  of  Trent  for  the  Traffic  Tight  ( STI)  [4] 


feel.  Currently,  there  are  many  tools  and 
products  on  the  market  that  make  the 
development  of  the  GUIs  easier  for 
embedded  applications. 

One  of  these  tools  is  the  Tilcon  IDS. 
Although  there  are  other  tools — such  as 
Altia  Design  and  the  Virtual  Avionics 
Prototyping  System,  which  are  in  many 
ways  similar  to  Tilcon — the  choice  over 
other  similar  tools  was  determined  using  a 
CMMI  Decision  Analysis  and  Resolution 
(DAR)  matrix  [5]. 

The  DAR  was  based  on  criteria  such  as 
customer  service  and  technical  support  by 
the  vendor,  operating  system  neutrality, 
cost  per  use,  development  seat  licenses, 
performance  of  the  solution,  ease  of 
development,  and  training  costs.  Each  was 
assigned  a  weight  factor  with  respect  to 
the  importance  for  the  project.  In  addi¬ 
tion,  a  small  prototype  was  implemented 
with  some  of  these  tools  to  serve  as  an 
input  for  the  DAR.  The  winning  solution 
was  selected  from  the  highest  cumulative 
score. 

The  UML  solution  was  designed  with 
the  idea  of  neutrality  to  the  GUI  develop¬ 
ment  tool.  Therefore,  if  the  choice  of 
Tilcon  no  longer  becomes  a  best-fit  selec¬ 
tion,  the  impact  to  the  UML  back-end 
solution  will  be  minimal  when  going  with 
an  alternative  GUI. 

The  Tilcon  IDS  (see  Figure  1)  consists 
of  three  main  components: 

1.  The  Tilcon  Interface  Builder.  The 
Tilcon  Interface  Builder  is  a  WYSI¬ 
WYG  GUI  design  tool2.  An  interface 
is  created  by  drag-and-drop  of  high-level 
GUI  objects  like  menus,  buttons,  text 
boxes,  labels,  etc.  Each  of  these 
objects  has  properties  associated  with 
it.  These  properties,  such  as  color, 
font,  size,  meter  range,  etc.,  can  be  tai¬ 
lored  to  meet  a  given  requirement.  As 
interface  development  is  applied  to 
each  object  so  the  application  pro¬ 
gramming  interface  (API)  can  manipu¬ 
late  it,  the  resulting  GUI  design  is 
saved  in  a  .twd  file.  The  Interface 
Builder  does  not  require  any  program¬ 
ming  skills  to  construct  a  GUI.  Non¬ 
programmers  such  as  graphic  artists 
can  use  the  Interface  Builder  to  con¬ 
struct  a  GUI.  It  is  highly  recommend¬ 
ed  that  a  naming  convention  be  fol¬ 
lowed  so  that  programmers  using  the 
API  can  access  the  objects  in  a  consis¬ 
tent  way. 

2.  The  Tilcon  Embedded  Vector 
Engine  (EVE).  The  EVE  is  a  plat¬ 
form-specific  engine  that  renders  the 
graphical  interface.  It  reads  the  same 
file  as  the  Interface  Builder  and 
ensures  that  the  GUI  is  exactly  the 


same  as  seen  in  the  Interface  Builder. 
The  EVE  runs  as  a  separate  process 
from  the  application  and  manages  all 
user  events  (button  presses,  mouse 
clicks,  etc.)  and  handles  the  screen  dis¬ 
play.  This  engine  is  available  for  many 
embedded  operating  systems,  such  as 
VxWorks. 

3.  The  Tilcon  API.  An  API  is  provided 
to  connect  the  EVE  to  the  application 
(see  Figure  1).  The  API  starts  and 
stops  the  EVE,  facilitates  communica¬ 


tion  between  the  application  and  the 
GUI  objects,  and  allows  objects  to  be 
created,  displayed,  modified,  or  delet¬ 
ed.  No  low-level,  platform- specific 
graphic  calls  are  required;  all  of  that 
work  is  handled  by  Tilcon  [6] . 

Merging  of  UML  and  a 
WYSIWYG  Interface 

Now  that  the  tools  have  been  presented,  it 
is  time  to  discuss  the  benefits  and  com- 


Figure  2:  Traffic  Tight  Advanced  Monitoring  System  States 
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Figure  3:  Traffic  Tight  Input  Structure 


mon  pitfalls  of  the  approach.  To  this  end, 
we  will  demonstrate  a  simple  example 
using  a  standard  traffic  light  with  some 
basic  gauges  for  the  GUI  presentation. 

For  example,  consider  Table  1  (on  the 
previous  page),  which  is  an  SEI  State 
Specification  Template  [7].  The  require¬ 
ments  for  the  traffic  light  state  that  in  addi¬ 
tion  to  correctly  changing  the  lights  from 
green  to  yellow  to  red  and  back  to  green,  it 
will  also  monitor  speed  and  pressure. 

The  I  IMF  solution  shown  in  Figure  2 
(on  the  previous  page)  is  completely  lan¬ 
guage-  and  platform-neutral;  because  the 
traffic  light  is  drawn  in  I  IMF,  there  is  no 
code  associated  with  it  (with  the  exception 
of  event  descriptions).  Therefore,  it  is  left 
for  the  auto-code  generation  engine  to 
translate  UMF  to  a  destination  language 
or  platform  of  choice;  in  this  case,  C++ 
[8].  As  a  result,  the  amount  of  source  code 
written  is  less  than  20  lines  of  code  for 
both  the  functionality  of  the  traffic  light 
and  monitoring  systems.  The  source  code 
written  in  C++  consists  of  timer  com¬ 
mands  in  the  form  cctimer.informIn(sec- 
onds)”  and  Tile  on  API  calls  to  the  graph¬ 
ical  objects  in  the  form  of  “TRT_Set 


Value (objectID,  value).”  The  Tilcon  API 
calls  can  be  replaced  one-to-one  with 
other  GUI  API  calls  such  as  from  Altia’s 
“AtSendEvent”  if  one  chooses  a  different 
front-end  solution. 

The  structure  diagram  in  Figure  3 
represents  system  events  that  are  used  to 
trigger  actions  on  the  state  diagram.  As  a 
result,  the  stimulus  to  these  events  is  pro¬ 
vided  by  the  system  itself  in  the  case  of 
the  timer  port;  as  well,  external  entities 
such  as  a  radar  detector  or  an  environ¬ 
mental  sensor  feed  back  data  updates  for 
the  other  ports. 

When  merging  WYSIWYG  GUI 
tools  with  UMF  on  a  complex  develop¬ 
ment  project,  it  is  of  the  utmost  impor¬ 
tance  to  exercise  good  OOP  and  spend 
effort  to  simplify  and  abstract  the  WYSI¬ 
WYG  GUI  as  much  as  possible  from  the 
rest  of  the  UMF  solution.  Abstraction 
will  allow  for  better  unit  testing  as  it  is 
possible  to  create  wrappers  that  can  sim¬ 
ulate  operator  display  and  input. 

The  GUI  in  Figure  4  was  quickly  cre¬ 
ated  with  the  Tilcon  Interface  Builder. 
This  tool  supports  a  drag-and-drop 
development  methodology  to  create  an 
interface,  which  consists  of  several 
graphical  objects  listed  in  Figure  5.  The 
figure  lists  the  object  structure  with  the 
type  and  identifier  of  each  object.  The 
entire  interface  was  created  and  tested 
without  any  UMF  or  programming  effort 
or  an  application  back  end. 

In  this  example,  the  description  of 
the  mechanics  of  the  speed  gauge,  pres¬ 
sure  gauge,  and  traffic  light  animation 
can  be  used  to  demonstrate  the  effective¬ 


ness  of  this  approach  at  the  front  end. 
Therefore,  it  is  of  interest  to  discuss  how 
these  objects  were  created  in  the  Tilcon 
editor. 

Traffic  Light 

The  image  for  the  traffic  light  in  Figure  4 
(created  in  Adobe  Photoshop)  was 
imported  into  the  Tilcon  Interface 
Builder  and  placed  into  a  state  object. 
One  of  many  types  available  in  the 
Interface  Builder,  this  object  type  can  dis¬ 
play  a  different  image  depending  on  its 
state,  which  can  be  changed  with  mes¬ 
sages  sent  to  it  through  the  API. 

Using  Adobe  Photoshop  with  the 
Tilcon  Interface  Builder  allows  for  an 
improved  visual  experience  for  the  end 
customer,  as  graphics  generated  are  gen¬ 
erally  more  visually  appealing  at  a  frac¬ 
tion  of  the  cost  otherwise  incurred  if  this 
was  done  in  any  other  way  (e.g.,  using 
C/C++). 

In  order  to  effectively  identify  the 
object  for  the  UMF  application  back  end, 
the  use  of  an  API-unique  ID  such  as 
“StateTrafficFight”  needs  to  be  assigned 
for  the  screen  name.  It  is  important  to 
note:  As  more  complex  GUIs  with  hun¬ 
dreds  of  graphical  objects  are  created  in 
the  Tilcon  editor,  a  strict  adherence  to  a 
naming  convention  will  be  required. 

Speed  Gauge 

The  speed  gauge  is  a  meter  object  that 
was  created  directly  in  the  Interface 
Builder.  This  object  is  a  standard  devel¬ 
opment  component  that  requires  a  mini¬ 
mum  effort  of  customization.  A  meter 
object  has  many  attributes — the  range, 
alarm  regions  (green  and  red  areas  in  the 
scale),  tick  marks,  fonts,  and  colors — that 
were  all  entered  in  the  Interface  Builder. 
For  this  example,  the  previously  men¬ 
tioned  attributes  were  slightly  adjusted 
for  the  visual  presentation. 

Speed  Gauge  Needle 

The  needle  for  the  speed  gauge  is  a  needle 
object  that  was  also  created  from  the  stan¬ 
dard  Interface  Builder  object  type.  The 
needle  selected  is  a  predefined  object  type. 
Several  predefined  styles  are  also  available 
or  a  custom  style  can  be  imported. 

Pressure  Gauge 

Fike  the  speed  gauge,  the  pressure  gauge 
is  a  standard  object  available  in  the  Tilcon 
Interface  Builder.  It  is  an  object  of  type 
“FillMeter”  that  represents  meter  posi¬ 
tion  with  a  fill  amount.  The  modifica¬ 
tions  for  visual  effects  were  primarily  the 
adjustment  of  the  visual  width,  font 
color,  tick  marks,  and  range. 
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-State  StateTrafficLight 

Example— —MeterBody  G^fleSpeed  -|_ 
—  Label  LabelSpeed 
—  FillMeter  GaugePressure 
-Label  LabelPressure 

Figure  5:  E xample  Object  Hierarchy 


Needle  NeedleSpeed 


Speed  and  Pressure  Label 

The  speed  and  pressure  labels  are  stan¬ 
dard  label- type  objects.  The  ID,  text, 
font,  font  size,  and  color  are  all  attributes 
that  were  entered  into  the  Interface 
Builder.  The  primary  effort  in  the  case  of 
the  labels  was  to  ensure  their  proper 
alignment  with  their  respective  objects. 

Once  the  graphical  objects  are 
entered  into  the  Interface  Builder,  the 
GUI  functionality  can  be  verified  with 
the  Interface  Builder  operation  “Run 
Test...  .”  This  mode  lets  the  GUI  design¬ 
er  verify  that  the  objects  operate  proper¬ 
ly  by  animating  their  behavior  without 
the  need  for  a  back-end  solution;  in  this 
case,  UML. 

What  Have  We  Gained? 

The  merged  solution  of  a  UML  and 
WYSIWYG  GUI  development  tool 
allows  for  several  advanced  flexibilities 
for  the  software  creation  effort.  Most  of 
those  flexibilities  are  geared  toward  rapid 
development  and  prototyping.  The  sepa¬ 
ration  between  the  front-end  WYSIWYG 
GUI  and  a  back-end  UML  provides  the 
kind  of  platform  development  combina¬ 
tion  that  can  bring  together  technical  and 
non-technical  development  efforts  seam¬ 
lessly. 

Non-Programmers  Collaboration 

Using  a  WYSIWYG  GUI  design  tool,  it  is 
possible  to  outsource  the  generation,  pro¬ 
totyping,  and  user  interaction  analysis 
effort  to  usability  experts,  graphic  artists, 
and  other  non-programmers.  They  no 
longer  need  to  know  anything  about  UML 
or  any  programming  language.  As  well,  a 
GUI  object-naming  convention  should  be 
followed  for  the  project.  This  will  allow 
programmers  to  access  the  objects  in  a 
consistent  way  [9] . 

Quick  Prototyping 

With  WYSIWYG  GUI  tools,  it  is  possi¬ 
ble  to  adjust  the  user  interfaces  in  a  mat¬ 
ter  of  minutes — even  in  the  field — rather 
than  hours  or  days  with  a  comparable 
native  programming  solution.  It  also  pro¬ 
vides  a  way  to  easily  evaluate  different 
approaches  that  otherwise  would  have 
taken  too  long  to  develop. 

Platform  Neutrality 

The  development  effort  for  the  GUI  is 
identical  regardless  of  the  deployment 
platform.  Whether  the  target  platform  is 
Windows,  Linux,  VxWorks,  or  another 
operating  system,  the  same  solution  is 
available  and  executes  identically  on  the 
operating  systems  previously  mentioned. 


Therefore,  it  is  possible  to  deploy  the 
same  solution  to  various  other  platforms. 

Ease  of  Unit  Testing 

WYSIWYG  GUI  development  tools 
allow  for  automatic  editor-based  debug¬ 
ging  of  the  GUI  designs  such  that  the 
prototype  solution  is  debugged  in  terms 
of  visual  actions  and  presentations  to  the 
operator.  This  allows  for  software  devel¬ 
opers  to  concentrate  more  on  the  UML 
part  of  the  solution  and  spend  more  time 
enhancing  functionality  and  quality. 

What  Have  We  Risked? 

As  one  might  expect,  there  are  always 
drawbacks  to  any  solution.  Over  the 
course  of  the  project,  several  pitfalls  of 
this  merged  tools  approach  have  been 
identified.  Here  are  some  of  the  key 
issues: 

Merging  of  Design  Files 

One  of  the  features  that  has  been  sorely 
missed  was  the  ability  to  merge  GUI 
design  files.  Because  the  design  resides  in 
a  binary  file  format,  the  source  control 
tool  could  not  merge  them.  Therefore, 
when  multiple  developers  work  on  the 
GUI,  developers  have  to  be  extra  vigilant 
when  checking  in  files  to  avoid  overwrit¬ 
ing  each  other’s  changes. 

WYSIWYG  GUI  Editing  vs. 

UML  Development 

There  is  a  fine  line  between  what  is  con¬ 
sidered  GUI  interface  functionality  and 
the  UML  back-end  functionality.  There¬ 
fore,  it  is  the  call  of  the  system  architect 
to  identify  the  separation  criteria.  When 
developing  in  a  WYSIWYG  GUI  tool,  it 
is  easy  to  get  carried  away  with  point- 
and-click,  advance  animation,  and  pre¬ 
sentation  development.  While  these  are 
great  options  for  some  projects,  they 
might  not  be  for  others.  Some  of  the 
functionality  that  belongs  in  the  UML 
part  of  the  project  should  not  be  moved 
over  to  the  WYSIWYG  GUI  develop¬ 
ment  tool. 

Let’s  say  someone  needs  to  rapidly 
change  more  than  100  objects  or  text  ref¬ 
erences  at  the  same  time  on  the  screen. 


One  approach  is  to  use  the  WYSIWYG 
GUI  development  tool,  which  results  in 
100  point-and-click  activities;  another  is 
to  implement  the  whole  thing  in  the 
UML  back-end  for  a  loop,  which  can  per¬ 
form  the  same  task  in  three  lines  of  code. 
The  risk  of  misplaced  functionality  can 
easily  wipe  out  the  gains  of  the  merged 
solution. 

Limited  Development  Language 
Support 

Most  of  the  WYSIWYG  GUI  tools  have  a 
predefined  set  of  software  languages  that 
they  support.  The  selection  of  the  WYSI¬ 
WYG  GUI  front-end  might  force  the 
choice  of  a  software  language  that  is  not 
in  the  best  interest  of  the  project,  or  same 
language  translation  must  occur.  For 
example,  if  someone  wants  to  use  Visual 
Basic  .NET  with  a  WYSIWYG  GUI  tool 
(such  as  Tilcon  or  Altia),  they  will  find  that 
it  will  not  be  supported  and,  therefore,  be 
forced  to  reconsider  going  with  C/C++. 
The  implication  of  code  generated  from 
UML  is  that  it  forces  a  restriction  to  what¬ 
ever  language  the  UML  tool  generates  and 
that  this  language  must  be  compatible 
with  the  API  supported  by  the  WYSI¬ 
WYG  tool. 

Conclusion 

The  example  presented  in  this  article 
shows  that  using  UML  for  the  back-end, 
run-time  engine  development  and  a 
WYSIWYG  GUI  builder  tool  for  the 
front-end  graphics  development  can  result 
in  overall  gains  in  productivity  and  ease  of 
prototyping.  The  event- driven  nature  of 
real-time  UML  facilitates  straightforward 
integration  with  an  event-driven  GUI;  to 
some  extent,  both  solutions  are  platform- 
neutral.  The  example  demonstrates  the 
ease  of  these  concepts  and  the  integration 
and  simplification  of  the  problem. 

One  of  the  key  benefits  of  this 
approach  is  that  non-programmers  can 
utilize  the  WYSIWYG  GUI  design  tool  to 
create  the  GUI.  Requirements  can  be 
expressed  in  UML,  and  these  descriptions 
can  be  used  in  the  design  and  implemen¬ 
tation  of  the  system.  As  a  result,  the  devel¬ 
opment  of  a  complex  system  is  simplified, 
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in  turn  minimizing  risk,  reducing  develop¬ 
ment  costs,  and  shortening  schedules.^ 
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Notes 

1.  In  the  Rational  Rose  RealTime  tool, 
active  classes  are  called  capsules ,  and  the 
associated  collaboration  diagrams  are 
called  structure  diagrams. 

2.  The  Tilcon  Interface  Builder  (see 
<www.tilcon.com/products/interface 
-development-suite/ tilcon-interface 
-builder>  to  learn  more)  is  not  to  be 
confused  with  the  Interface  Builder 
application  for  the  Apple  Mac  OS  X. 
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